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[57] ABSTRACT 

In a main embodiment, preslage filtering is applied via 
user-definable filter parameters (e.g., reject, pass, or granu- 
larity filters) on data being transferred between a commu- 
nication unit (201) and communication server (220). For 
downloading, e.g., email from a host post office (240), a 
communication server controller (229) preferably either 
forwards the filter parameters in a query object or message 
to the post office to apply and return qualified mail 
(406-414), or the communication server receives all unproc- 
essed mail and applies the filters locally (418-420), only 
acknowledging as processed that mail which passes the 
filters. For uploading, e.g., email from a client, a client 
controller applies an upload prestage filter (432) so as to 
retain all filter- rejected email, while transmitting email pass- 
ing the filters (434). Thus, only desired data transfers (i.e., 
those meeting user defined filters) are communicated over 
the expense-bearing networks between the remote unit and 
communication server. 

11 Claims, 8 Drawing Sheets 
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SYSTEM FOR COMMUNICATING 
USER-SELECTED CRITERIA FILTER 
PREPARED AT WIRELESS CLIENT TO 
COMMUNICATION SERVER FOR 
FILTERING DATA TRANSFERRED FROM 5 
HOST TO SAID WIRELESS CLIENT 

The present application is a continuation of U.S. appli- 
cation Ser. No. 08/574,537, filed Dec. 19, 1995 now 
abandoned, entitled "Method and Apparatus for Virtual lO 
Session Communications" by Gene Eggleston and Mitch 
Hansen, commonly owned together with this application by 
Motorola, Inc. 

HELD OF THE INVENTION 15 

The present invention relates to communications and 
more particularly an improved method and apparatus for 
transferring data in a communications system. 

BACKGROUND 20 

The last 10 years have seen a tremendous increase in the 
demand for communications services, including both wired 
and wireless networks capable of handling data communi- 
cations. Unlike real-time voice services, such as standard 25 
telephony or cellular wireless services, in which circuit- 
switched communications are used because of the sensitivity 
of users to the timing of oral dialogueA^oice data, greater 
efficiencies can often be achieved in non-voice data com- 
munications through the use of packet-switched or hybrid 
communications systems. This is particularly the case with 
communications to remote users (e.g., persons sending 
messages via one of the well-known available wireless 
networks like GSM (Global System for Mobiles) or AMPS 
(Advanced Mobile Phone System) cellular), where pro- 35 
tr acted circuit-switched sessions into a mail server or LAN 
(local area network) could be prohibitively expensive due to 
the high per-minute session charges by the wireless service 
provider. 

One solution to this problem has been for users to limit, 40 
as much as feasible, their communications to sessionless 
communications. This can be done, e.g., by subscribing to 
additional email services that can receive LAN/WAN (wide 
area network) email and send out broadcast pages and 
transmissions to registered users, in lieu of requiring a user 45 
to maintain a session with a mail server. However, this 
disadvantageously requires subscription to an additional 
service, and is typically limited in the types of applications 
supported. With the rapid growth in emerging session- 
oriented applications — like the popular chent server appli- 50 
cation of Lotus Notes® — the need is growing for more cost 
effective solutions to providing connectivity of such session- 
oriented applications and users remotely located from their 
host servers. 

Regardless of whether a session-oriented or session -less 55 
communication service is used, it is also desirable to limit 
the amount of information communicated between a remote 
user and host, both to save off-site user's time and to limit 
the costs arising from the more expensive rates for remote 
communications. Unfortunately, typical applications like 60 
email do not provide for user-selected methods for choosing 
and limiting the volume of down-loaded communications, or 
for filtering uploaded communications. Thus, a user who 
wants to receive remote messaging is left with an option of 
receiving all his messages, even the ones he or she might 65 
otherwise be willing to leave unread until a later time when 
no longer using expensive remote communications services. 



2 

Further, many processes, like that of a typical email reply, 
are wasteful of bandwidth by resending all earher messages 
each time a new reply is generated, even though the earlier 
messages may still be stored at both ends of the wireless 
network. 

In addition to the above concerns over how to optimize 
the types and amount of data being transferred, there is 
additionally a problem in a lack of effective techniques for 
monitoring and even controlling an aggregate use of tariffed 
networks. While the network service providers have means 
for tracking use by an individual unit basis, which is totaled 
in periodic billing statements, this information is typically 
unavailable to users or their managers/application adminis- 
trators. Thus, users and managers are typically left without 
any effective means for controlling the level of messaging 
during a billing cycle, and can only monitor or react to usage 
following the service providers periodic statements. 

There remains therefore a need for an improved means for 
data communications that solves these and related problems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a communications system 
according to a first embodiment of the invention; 

FIG. 2 is a block diagram of a communications system 
according to a ftirther embodiment of the invention; 

FIG. 3 is a flow chart illustrating virtual session data 
transfer between the different functional entities of the 
wireless communications system of FIG. 2; 

FIG. 4 is a flow chart illustrating a pre-stage filtering 
embodiment for data transfer between the different fimc- 
tional entities of the wireless communications system of 
FIG. 2; 

FIG. 5 is a flow chart illustrating one embodiment of 
pre-stage filtering for data transfers; 

FIG. 6 is a flow chart illustrating another embodiment of 
pre-stage filtering for data transfers; 

FIG. 7 is a flow chart illustrating a message summariza- 
tion and selection embodiment for data transfer between the 
different functional entities of the wireless communications 
system of FIG. 2; 

FIG. 8 is a diagram illustrating an embodiment of a 
summary index for use in the process of FIG, 7; 

FIG. 9 is a flow chart illustrating an optimized reply 
embodiment for data transfer between the different func- 
tional entities of the wireless communications system of 
FIG. 2; and 

FIG. 10 is a flow chart illustrating a rate governor 
embodiment for data transfer between the different func- 
tional entities of the wireless communications system of 
FIG. 2. 

DETAILED DESCRIPTION 

These problems and others are solved by the improved 
method and apparatus according to the invention. A pres- 
ently preferred first main embodiment of the invention is a 
system including a virtual session manager (VSM) for 
establishing and maintaining a sessionless communication 
path with a first data processing device (e.g., a mobile client) 
on the one hand and a session-oriented communication path 
with a second data processing device (e.g., a host system). 
The session-oriented communication protocol with the host 
system permits remote access to, e.g., LAN-based 
applications, while the virtual session, via a sessionless- 
oriented communication protocol, between the VSM and 
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remote (i.e., coupled via a tariffed network or connection) main rate governor is maintained at the communication 

client permits this access to be carried out without the server, allowing access, control and the like by system 

expense of a dedicated/circuit switched connection. administrators and the like. A further rate governor, respon- 

In a second main embodiment, a preslage filter stage is sive to the main rate governor, may also be used at the 

provided for applying user-definable filter parameters (e.g., 5 remote unit. By means of this rate governor a mechanism is 

reject, pass, or granularity filters) on data being transferred provided for both limiting user or group data transfer beyond 

between the remote communication unit and communication a set amount, as well as providing alerts to users as the limit 

server. For downloading, e.g., email from a host post ofiSce, is approached. 

a communication server controller preferably either for- Turning now to FIG. 1, there is generally depicted a 

wards the filter parameters in a query object or message to communication system 100 in accordance with a first 

the post ofiBce to apply and return qualified mail, or the embodiment of the invention. This system is configured to 

communication server receives all unprocessed mail and support one or more user devices such as wireless subscriber 

applies the filters locally, only acknowledging as processed units (i.e., mobile station (MS) 105) communicating with 

that mail which is qualified. For uploading, e.g., email from host processor 115 via an infrastructure including base 

a client, a client controller applies an upload prestage filter station 120 and intermediate system 125 coupled to a data 

so as to retain all filter rejected mail, while transmitting mail network 130. In the illustrated case mobile station 105 is a 

passing the filters. Thus, only desired data transfers (i.e., portable computer having an rf (radio frequency) modem 

those meeting user defined filters) are communicated over 106. A communications server 110, including a virtual 

the expense-bearing networks between the remote unit and session manager (VSM) and query manager (QM), is 

communication server. 20 coupled between the public data network 130 and the host 

In yet another main embodiment, a select and summary server 115. The virtual session manager and query manager 

(S&S) listing or index is used to provide user flexibility in are, preferably, an appropriately configured data processing 

reviewing and requesting otherwise filtered data. Both the device, the VSM and QM program being shipped for loading 

user's remote communication unit and communication on the server 110 via any convenient means such as a 

server maintain a S&S index containing identifying 25 machine-readable CD-ROM 111 (compact disc-read only 

(summary) information about data which has not been fully memory) or the like. Counterpart client-communications 

transferred between the communication unit and communi- software, e.g., a prestage filter and rate governor, can be 

cation server. As new data is reviewed and filtered for shipped via a similar convenient form like CD-ROM 107, 

transfer, identifying/summary information is captured for downloaded directly from server 110 to subscriber 105 (also 

any non -qualifying data by either a host unit or the com- 3Q being, e.g., a data processing device, by which is meant 

munication server. This iiiformation is stored in the com- virtually any processor (but not a human) capable of pro- 

munication server's S&S index, and at least periodically cessing data for a programmed result, whether a general 

transferred via update messaging to the remote communi- purpose computer or more specialized electronic processor), 

cation unit. Upon reviewing its updates or its S&S index, the or the like. 

user may send a request for such of the data that it desires 35 In this embodiment the mobile user 105 communicates 

partial or full transfers for further review. Thus, a cost with the serve r/VSM 110 using any appropriate data proto- 

efiScient review mechanism is provided to users for deter- col being used by the data network 130, as necessarily 

mining whether to transfer data that otherwise fails selected modified for transport over the wireless infrastructure; the 

filter parameters. wireless infrastructure could be, e.g., any private system like 

In a fourth main embodiment, a method and apparatus for 40 ARDIS® or DataTAC®, CDPD (cellular digital packet 

optimized reply to messaging is provided. When sending a data), GPRS (GSM Packet Radio Service), and the like, 

reply, the remote communication unit's controller generates Thus, a sessionless data flow t?etween the mobile user 105 

a delta (e.g., data representing the content difference and serverA^SM 110 occurs on an event driven basis, and no 

between two messages) between a preceding message and costly connection is maintained when there is nothing being 

the reply message, and forms an optimized reply using the 45 communicated. In order to keep connectivity costs to a 

delta and an identifier of the preceding message. On receiv- minimum, the server 110 is preferably connected to the 

ing the optimized reply, the communication server uses the LAN/WAN on which the host 115 is also connected, via any 

data unit identifier to retrieve the preceding message from a standard LAN/WAN communication channel (e.g., a bus or 

further host (e.g., the post ofiGce mailbox of the user asso- backbone). This allows the communications server 110 to 

ciated with the remote unit), reconstructs the full reply from 50 advantageously maintain the same session with the host 115 

the retrieved message and the delta, and forwards the full that the client 105 typically enjoys when connected to the 

reply to the addressee. When receiving a reply for the remote LANAVAN. Thus, by use of the server 110 the client 105 can 

unit, an index is preferably maintained at both the remote achieve a virtual session with the host 115 with almost the 

unit and communication server of mail stored at the remote same access as if directly connected to the host's 115 LAN, 

unit. Resort is made to this index to determine a preceding 55 but at a substantial reduction in the cost of communicating 

message forming part of the reply. An optimized reply is via the wireless network and PDN 130. 

similariy formed from a delta and identifying information of FIG. 2 illustrates an alternative communication system 

the preceding message, and sent to the remote unit. In this 200 embodiment of the present invention. A first client, a 

manner, the volume and expense incurred in reply messag- mobile end system (M-ES) computer including a user device 

ing is greatly reduced, by only sending a delta and small 60 201, is in communication with a base station (BSl) 218 of 

header (i.e., the identifying information). a wireless communication system. This base station 218 is 

FinaUy, in a fifth embodiment, a rate governor is provided coupled, e.g., on a same bus or via bridges/routers, to a 
for monitoring and controlling the amount of communica- communication server 220 which includes VSM 230. An 
tions between the remote unit and communication server. electronic mail (email) post office is coupled locally to VSM 
Preferably, as threshold(s) are passed a user is alerted to 65 230, either as another program running on the same corn- 
amounts (time and/or charges) spent or remaining, and once munica tions server 220 or located on another server 240 of 
a use limit is reached further communication is restricted. A the communications server's 220 LAN/WAN. It is not 
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important, however, where the post ofiBce is located for and client 201; these include, e.g., appropriate protocol 
purposes of operation of the VSM 230, as is illustrated by software that can be located at the communications server, 
other application hosts B and C 255, 260 being in commu- or any other convenient processor per design of the given 
nication via other networks such as a public data network or communication system. By messages is meant any appro- 
public switched telephone network 250. In fact, the same 5 priale data unit (whether a frame, datastream, packet, or 
user 201 could be concurrently coupled via the VSM 250 to, other format), including objects, datagrams, etc., for con- 
for example, a local email post oflSce 240, a remote client- taining information being communicated, 
server host 255, a further database host server (not shown), Communications server 220 is also illustrated as support- 
an administrator host server 260, a multimedia host, a voice ing additional users, e.g. user module 216, communicating 
processor, etc. It should be understood that for purposes of via different access points, e.g., control module (CM) 217 of 
this application, a first device or component is responsive to a wireless LAN and base station 219, all access points 
or in communication with a second unit or component 217-219 being coupled via a common bus, backbone, etc. 
regardless of whether the first and second units are directly lliese base stations can be part of the same communication 
coupledorindireclly coupled, such as via intermediate units, system, similar systems owned by different service 
including switches that operatively couple the units for only 15 providers, or even different systems, all of which may be 
a segment of time, as long as a signal path can be found that different from the communications server service provider, 
directly or indirectly establishes a relationship between the Thus, for example, a single communications server can 
first and second units. For example, the client computer 105 support at one local region 215 an ARDIS® node, a RAM® 
is in communication with the VSM server 110 even though node, a wireless LAN controller module, a CDPD node, an 
intermediate system (e.g., a router or switch) 125 and a 20 in-building cordless telephone node, etc., allowing users 
packet network 130 having multiple switches etc. are dis- from a variety of systems to access the same communica- 
posed between the user device 105 and VSM server 110. tions server and post office. Users not registered could 

In the illustrated case client 201 includes a data transfer access through the appropriate one of these nodes along the 

manager or exchange unit 206, which in simple form could model of FIG. 1, i.e., via PDN 250 to a remote communi- 

be an appropriately programmed electronic processor 207 25 cations server having their VSM/QM. Thus, any number of 

(e.g., a general purpose CPU (central processing unit) and system configurations is possible, limited only by the net- 

memory or data store 211. A timer 205 is also preferably work services provided and the user*s preference, 

employed in the data exchange control process, as will be A process by which a VSM manages communications 

explained further in connection with the flow chart of FIG. between client and host is illustrated in the flow chart 

3 below. A typical client 201 would also include some 30 embodiment of FIG. 3. This process typically begins with a 

form(s) of user interface such as display 204, a data encoder/ user event, such as instantiation (forming) of a communi- 

decoder 203 to accommodate the system communications cations object at the client and sending a registration mes- 

protocol(s), and a transceiver (if using rf or infrared sage (steps 301-302). Alternatively, the infrastructure could 

communications) and a modulator-demodulator (or modem) initiate the communications by sending a page or the like 

202 to connect to a wireless or wireline communications 35 requesting the client to register (for example, when the client 

network. Transceiver/modem 202 in this case would either has registered with the wireless system but not yet requested 

include a built-in or attached user module for wireless LAN registration with the communications server). In any event, 

communications; the specific type will vary depending on once a registration message is received by the communica- 

the system, e.g., including PCMCIA (personal computer tions server, it preferably authenticates and otherwise quali- 

memory card interface association) wireless modems, and 40 fies the client, including sending a logon/registration mes- 

attached or built-in PSTN (public switched telephone sage to the host for its authentication of the client (steps 

network) modem, etc. Specific features of data exchange 303-305). Upon successful authentication, the communica- 

unit206preferably includes (as more fully described below) tions server instantiates a client object (CO) for the com- 

a prestage filter (PSF) manager 208, rate governor (RG) 209, munications session including client parameters retrieved 

user profile store 212, select and summary index store 213, 45 from an inactive client parameter store, as modified by the 

and mail store 214 (a store being any available device (e.g., user in his registration or subsequent messages (step 306). 

ROM (read-only memory), disks) or program (e.g., a These parameters include at a minimum client and host 

database) for storage of the specified information). identifiers, but may also include additional preferences 

The communication server 220 preferably includes a data based on the type of communications involved. Also, the . 

transfer manager or controller 229 having a VSM 230, 50 registration and authentication process can be handled by the 

memory stores for storing active client profile (user VSM, or alternatively by another appropriately programmed 

parameters) and inactive client profile information 226 and entity of the communications server. Following instantiation 

227, a timer 224, and optionally some form of protocol at the server, a response message, e.g., a further registration 

translators or formatters 222. The VSM 230 serves to message, is sent to the client, and an acknowledgment 

manage the virtual session with the client 201 and session 55 (ACK) returned to the server; both client and server then 

with host systems 240, 255 and/or 260 based on the param- retain the instantiated objects as fully qualified, and start 

eters loaded into the active user parameter store/profile session timers (steps 307-309). At this point a virtual session 

memory 226 or object. Controller 229 preferably also has been established between the client and the VSM, and a 

includes a query manager (QM) 231 for controlling specific regular session established between the VSM and host 

processes (e.g., sending messages lo a post ofiSce to query 60 computer. If the registration is not successful, then any 

for unprocessed messages and forwarding received mes- instantiated object is deleted, with the client returned to an 

sages etc.), and a prestage filter 232 and rate governor 234. inactive status. 

Memory 225 also preferably includes a client select and Upon establishing the virtual session, a query is prefer- 

summary index database or store 228, which will also be ably generated by query manager requesting unprocessed 

described more fully below in connection with FIGS. 7 and 65 data for the user, and the VSM forwards the query to the host 

8. The protocol translators 222 serve to format or code the (step 320). In the case of email, e.g., this might include 

messages as appropriate for transport between the VSM 230 generating a request message for all unread mail in the users 
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post ofBce box. The post ofiBce then checks for new mail with the generation of a query object or message at the 

received, and forwards all such mail to the VSM (steps communications server (step 406). TTiis object/message may 

321-322). Because the VSM has established a LAN session be created in response to a preceding client generated 

with the post ofiBce, these communications are performed message (e.g., a request generated when clicking on an 

relatively quickly, e.g., in accordance with the LAN's and 5 application button requesting updates, executing the mail 

host's typical processing for their current loading level. The application, etc.), or in response to settings in the client 

VSM in turn forwards the data (i.e., mail) received via the profile. However, after updating the active client profile/ 

virtual session transport (step 323). For example, in the case object for an active client application, the query manager is 

of FIG. 1 where PDN 130 is an ISDN (integrated services preferably programmed to send query objects at predeter- 

digital network) network connected to a CDPD wireless jq mined intervals for each application being run by each active 

network, the mail would be appropriately packetized by the client, the intervals varying depending on the application 

communications server and delivered via the serving BS 120 type (e.g., longer for mail (about every 5?* * ♦ seconds) than 

according to ISDN/CD PD system protocols. This can take for interactive applications like Lotus Notes (about every 

up to several minutes or more for a moderately sized mail I?*** second). Alternatively, the intervals could be user 

package. However, since the data is being delivered in a ^5 specified via the client profile, for example to shorten the 

sessionless mode, the amount of time the communication query intervals for time critical applications (e.g., for emer- 

channel (including the more expensive wireless communi- gency services or "real time" applications), or lengthen the 

cation channel portion, as well as the portion via PDN 130) intervals when less frequent updates are desired (e.g., to 

is tied up is kept to a minimum. This also translates into a conserve on traffic expenses for updates to a rapidly 

significant cost savings for the user, since the user is only 20 changing, but non-time critical, group-ware file or 

charged on a per packet basis for mail when it is actually document). 

transported, and doesn't have to pay for a prolonged session xhe content of the query objects will vary depending both 

to keep connected to the post office in order to receive new upon the application and client filter settings. One approach 

mail. Finally, upon receipt by the client, appropriate for mail applications is to have a predetermined number of 

acknowledgments are sent and the post office box updated, 25 user-definable filter attributes stored in the client profile 

e.g., by marking the mail as read or processed (steps databases (e.g., stores 212 and 226-227 of FIG. 2). These 

324-326) attributes can include, by way of example, the priority of a 

While in some systems it may be advantageous to store message (e.g., urgent, normal, or low); the dale on which the 
some of the data at the communications server, in the case message is sent or posted; the size of the message (typically 
of email and the like it is presently envisioned that the 30 uncompressed, i.e., the nonmal stored size; although trans- 
communication server is preferably used in maintaining the mission size or cost could also be used); the author of the 
sessions between client and host, and not as a remote server message; and the subject of the message (e.g., key words in 
for the host. Thus, rather than have all new data from the a subject line or in the text), lliese attributes can simply be 
host pushed down to the communications server, most data used as reject criteria (e.g., reject all messages having "low" 
exchanges are preferably initialed, at some predetermined 35 priority, date before "12/15/95", size more than "2" kbytes 
interval or intervals, by the communications server (e.g., by (kilobytes), or subject not containing "project x"), pass 
the query manager). criteria (all messages from "Boss") or a combination of both, 

Further, it is an inefficient use of resources to continue the variety and complexity being a matter of design choice, 
querying a host or attempting to deliver data when the client These attributes also preferably include certain "granularity" 
is no longer receiving at its remote location (occurring, e.g., 40 filters, i.e., filters additionally limiting the size of a message 
when the client leaves a coverage area, or the user turns ofif passing all or most of the other filters. Three possible 
its modem or processor). Thus, a process for either main- examples of granularity filters are a truncation size filter 
taining the client in an active status, or removing the client (e.g., truncate the message after the first "100" bytes), and 
from active status in response to an event, is also preferably text or file attachment filters (e.g., indicating whether or not 
included in the VSM. One such process is to utilize timers 45 to strip attachments). Thus, messages passing all criteria but 
at both client and VSM to determine when a virtual session message size could still be received in a truncated size 
is no longer active. The timers are first set upon registration, meeting the message size criterion. Alternatively, messages 
and are subsequently reset after each data exchange (steps failing the author or subject filters could still be passed with 
327-336). If no data exchange occurs within a predeter- header information, by setting all rejected messages to be 
mined period of time, say 20 minutes, both client and VSM 50 passed with a text truncation size of "0*' bytes. One skilled 
would remove the client qualification (i.e., destroy the client in the art will appreciate that a variety of other reject/pass 
object for the communication session) and, if desired, mark filter criteria may be used, and the specific ones and com- 
the client as being in an inactive status (steps 337-340). The binations of user-definable (or even administrator-definable) 
VSM would also forward a logoff message to the host (step features will be largely a matter of design choice depending 
341). In order to avoid an undesired time out, the client is 55 on factors such as the desired functionality, complexity, and 
preferably configured to send a short message after a pre- application(s) (including filterable features). It is significant, 
determined period since the last data exchange, sufficiently however, that clients are now provided by the present 
prior to the time at which the timers elapse so that the VSM invention with a means for effecting prestage filtering of 
can receive it. Otherwise, if there are only intermittent data their communications by virtue of the communications 
exchanges, the client may be required to frequently eo server and definable filter settings, rather than having to 
re-register; this in mm means the client will not be notified choose between receiving no messages or receive all 
of outbound data until the client re-registers and is again messages, including less important or expensive and time- 
coupled via the virtual session manager. consuming transmissions. 

Turning now to FIGS. 4 through 6, a presently preferred The prestage filtering is preferably performed at the host 

embodiment is shown for prestage filtering data for transfer 65 server. This may be accomplished, for example, by passing 

between the different functional entities of the wireless the filter attributes in an appropriately formatted query 

communications system of FIG. 2. This typically begins object or message for use by the host application. In the 
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illustrated case a query object with the client filter settings 
is forwarded to the post office, and applied by a communi- 
cations server object or CSO (instantiated at the post office 
when the virtual session is established). The post office/CSO 
reads/queries the query object for the filter attributes, and 
applies these criteria in the selection and formatting of 
unprocessed messages (steps 408-412). The filtered mes- 
sages are then encapsulated and forwarded to the QM, which 
similarly forwards the filtered messages (with appropriate 
protocol translation) to the client (steps 414-416). 
Alternatively, where the host application is not designed to 
permit prestage filtering, all unprocessed messages can be 
forwarded to the communications server, where the filters 
are applied via a prestage filter (PSF) object or routine (e.g., 
PSF 232 of FIG. 2), with only qualifying/filtered messages 
being forwarded to the client (steps 410, 418-424). Through 
acknowledgments the post office is notified how to mark the 
mail index in both cases. For example, when prestage 
filtering at the post office, all forwarded mail would be 
marked as processed/read and all filtered mail as unproc- 
essed (truncated messages being marked as either depending 
on design conventions, or if available marked as filtered or 
partially processed). If prestage filtering is done at the 
communications server only those messages forwarded to 
the client would be acknowledged and marked as processed 
(step 428). 

In addition to download/downlink filtering, prestage fil- 
tering is also advantageously used in upload/uplink trans- 
missions. This can take the form of granularity filtering, or 
automatically retaining the whole data unit or message based 
upon filterable attributes for later transmission when on a 
lower cost network. In this case, each client would have a 
prestage filter (PSF) unit such as that of PSF 208 of FIG. 2 
(e.g., a PSF object or routine drawing on selected attributes 
in the profile store 212). Each data unit generated is filtered 
using the user-selected criteria, with qualifying data being 
forwarded via the communication server (steps 430-436). If 
a data unit is not sent, it is retained locally for transmission 
later, e.g., when connected via a lower cost network to the 
post office. As an enhancement, the user could additionally 
be provided with a selection of types of send buttons (i.e., 
fihered send or unfiltered send), or be prompted with an alert 
dialogue or similar message when a message is filtered to 
decide whether to forward the data unfiltered (steps 
438-440). Similarly, the user can be provided with several 
groups of filler settings that could be manually or automati- 
cally activated, so as to enable the client to adjust plural filter 
settings with a minimum effort, for example by switching to 
a more restrictive profile when entering important meetings 
(which profile could be automatically activated via an appro- 
priately configured and coupled calendar program, etc.). 

While only the client need retain the upload filter 
attributes in its profile store, preferably both the communi- 
cation server and client store copies of the download filter 
settings in their profile memories. This conveniently permits 
a client to review all settings whenever desired, and to 
change the settings locally. When the download settings are 
changed at the client, the changes are communicated to the 
communication server preferably as soon as the change is 
made, or as soon as a virtual session is established if the 
changes are made while offline from the communication 
server (steps 442-444). Further, where a summary index of 
filtered messages is maintained (as is described in connec- 
tion with FIGS, 7 and 8 below), upon a change in filter 
settings the communication server may be automatically set 
to forward all messages previously rejected but now passing 
the new filter settings. 
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FIGS. 5 and 6 illustrate two approaches to prestage 
filtering particularly useful for email filtering. In FIG. 5, a 
series of five reject filters are applied to each message. If a 
mail message does not meet any of the criteria (priority, date, 

5 size, author, or subject/key word) then it is left unprocessed 
(steps 502-516). Once all unreviewed messages (i.e., all 
unprocessed messages, or if expanded marking is available 
all unprocessed messages not previously filtered) have been 
filtered, those not rejected are forwarded (step 518). FIG. 6 
illustrates the application of granularity filters. If a message 
exceeds the filter size, it is appropriately truncated 
(including insertion of a note indicating truncation) (steps 
602-606). Similarly, if there are text or file attachments, and 
these are marked to be filtered, they are stripped with, 

J 5 optionally, a note being inserted alerting the addressee that 
the attachment was stripped (steps 608-614). Once filtered, 
the message is sent (step 616), 

FIGS. 7 and 8 illustrate a further enhancement, permitting 
the user to more conveniently review selected information 

20 even for filtered/rejected data. In the preferred embodiment 
a query object or message is similarly generated by the 
communication server as described above. However, in 
addition to the profile information, the query object in this 
case includes a request for summary information about each 

25 partially and fully rejected message (step 702). When the 
host (i.e., a post office server in the illustrated case) receives 
the query it applies the appropriate filters; if only qualifying 
mail is present, this is forwarded to the client as described 
above (steps 704-708). Where there is partially (e.g., 

30 truncated) or fully rejected data, identifying summary infor- 
mation is captured for all rejected data (step 710). For mail 
this identifying summary information would include the 
message serial number, along with certain header informa- 
tion (801 and 802 of FIG. 8). This header information may 

35 include any filterable attribute (e.g., date, author, subject, 
size, priority, attachment indicator) and is preferably client 
definable, so the client can decide how much header infor- 
mation it needs and how much to omit. All qualifying and 
non-qualifying (i.e., filter-rejected) mail is marked similarly 

40 as described above (step 712), 

When the response object or message is received by the 
QM of the communication server, the encapsulated identi- 
fying summary information is saved to a select and summary 
(S&S) index, such as that illustrated by client S&S index 

45 database 228 of FIG. 2 and the index structure of FIG. 8. 
This index is preferably created in response to the first query 
following full qualification, although one could retain a 
stored index when the client is inactive as long as the index 
is fully updated upon re-registration/qualification. In order 

50 to minimize transmissions between the communication 
server and the client, only changes to the S&S index are 
forwarded, as summary delta data (i.e., a delta of the revised 
index to the immediately preceding index, the preceding 
index being an acknowledged version same as that stored in 

55 the S&S index (e.g., S&S index database 213 of FIG. 2) of 
the client). Where only identifying summary information is 
received in response to the query object, one may addition- 
ally delay forwarding the delta information to the client for 
a predetermined period of time or until the next message 

60 passing the prestage filters is forwarded, whichever comes 
first (i.e., the filter-rejected information more likely being 
less important, some users may prefer to receive S&S index 
updates less frequently in order to further reduce costs or 
interruptions) (steps 714-718). 

65 Upon receiving the delta of the identifying summary 
information, the client updates its S&S index and, when 
appropriate, prompts the user (again, the prompt criteria 
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could be set for all messages, or some sub-set based on any 
filterable attribute, etc.). The user is thus able to review the 
summary informatioD and make a determination on whether 
or not to override the filter rejection. For mail the user wants 
to read, the user indicates the decision by any appropriate 
means (clicking on the message, voice command, etc.) and 
an appropriate request generated (e.g., for all selected mail, 
for only a partially filtered version (e.g., truncated), etc.) 
(steps 720-722). The request is appropriately translated, as 
needed, and sent as a query object or message to the post 
office. Upon retrieval, the requested data is forwarded to the 
client via the QM. Upon receipt at the client, a read 
acknowledgment is generated and sent to the communica- 
tion server. Preferably when the read acknowledgment is 
received at the communication server a further ACK 
(acknowledgment signal) is sent to the client, at which time 
both client and communication server update their respec- 
tive S&S indices to remove the entry for read mail from the 
S&S index, and note any partially read mail. Upon 
acknowledgment, the post office further marks any read mail 
as processed (steps 724-734). 

As with prestage filtering, one skilled in the art will 
appreciate that many more filterable attributes and summary 
inputs are possible than those described, and which ones are 
available will depend on such factors as the desired 
functionality, complexity, and application(s) (including fil- 
terable features) for which the select and summary index is 
being used. The index structure may thus similariy vary 
significantly, as will the means for achieving similar indices 
for both the client and communication server; in other 
words, while one could simply periodically forward the 
whole index, where practical any one of a number of known 
delta (e.g., data representing the content difference between 
two files) or other update approaches for communicating 
less than the whole index are likely more preferable. What 
is significant, no matter the particular design approach 
selected, is that a summary index, showing unprocessed or 
partially processed data (e.g., that filtered), is available to a 
client for determination on whether to process the data 
further, with a substantially identical index being retained at 
the communication server in order to further reduce trans- 
mission requirements. 

FIG. 9 illustrates a yet further improvement, this embodi- 
ment permitting a user to minimize the data transmitted for 
responses to earlier data transmissions. This is particularly 
advantageous in the case of email, where it is common to 
append all prior messages in an email conversation to a 
reply, making for lengthy reply messages that contain sub- 
stantial portions that are identical to mail already saved at 
the client or target unit. While this has come to be expected 
in email replies, it is also quite costly in time and tariff 
charges in bandwidth limited systems like most wireless 
communication systems. 

Starting from a client perspective, the process of FIG. 9 
commences with a client formulating a reply to a received 
mail message, much as he or she would for any typical email 
application (step 902), However, when the user executes the 
reply, e.g., by clicking on a send button, the client controller 
(201 of FIG. 2) optimizes the reply message by calculating 
a delta or difference, using any appropriate delta routine, 
between the reply message and the preceding message. This 
delta is then formed into an optimized reply along with a 
message/data unit identifier for the preceding message/data 
unit (preferably the mail serial number, although any retriev- 
able identifier of the preceding message may be used, such 
as header information, or even a CRC (cyclic redundancy 
check) value) (step 904). To ensure that only the shortest 
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message is being sent, the controller additionally compares 
the reply message with the optimized reply to determine 
which is optimum for transmission (step 906), This deter- 
mination may be made based on a comparison of the 

5 message sizes, compressed and formatted message sizes, or 
any other convenient means for estimating which version of 
the reply will require the least bandwidth or transport cost. 
Thus, for example, a normal reply message to a very short 
message may be selected for transmission where the over- 
head of the delta and message identifier make the optimized 
reply bigger than the normal reply message would be. 
However, in most instances it is anticipated that the opti- 
mized reply will be smaller than a normal reply message, 
providing significant savings to the client in time and costs. 

35 When the optimized reply is received at the QM of the 
communication server, a determination is made on whether 
to reconstruct the normal reply message (i.e., form a replica 
reply) or to forward the optimized reply, based on known 
parameters (if any) of the target communication unit/client. 

20 Thus, for example, where both the originating and target 
clients are active and served by the same communication 
server and thus are known to have optimized reply 
capabilities, and the target client was an addressee or origi- 
nator of the preceding message identified by the message 

25 identifier of the optimized reply, a reconstructed reply is not 
required. Rather, since the preceding message is either in the 
inbox or outbox of the target unit, the target unit can 
reconstruct the reply message from the identified mail in its 
mailbox and the delta. This advantageously allows band- 

30 width to be minimized for both the sending and target 
clients. Further, if perchance the target unit has already 
deleted the identified preceding message, the controller of 
the target unit could, rather than acknowledge receipt, send 
a request for the normal reply message, which the commu- 

35 nication server would reconstruct as described next. 

In cases where the target unit is not an active client with 
the communication server, the QM (or other appropriate 
entity of the controller) functions to reconstruct the reply 
message from the optimized reply. Because the communi- 

40 cation server preferably does not retain a copy of client mail 
or data located on other hosts (such remote stores typically 
adding complexity and cost, while being unnecessary in 
view of the virtual session established via the communica- 
tion server), it would use the identifier to retrieve the 

45 preceding message from the host (e.g., send a query object 
or message to the appropriate post office) (steps 908-912). 
This can be implemented by requesting the preceding mes- 
sage from the client inbox, or from the originating unit's 
outbox (or even the target unit*s inbox, if it is a cc: on the 

50 preceding message). Because the serial number is a unique 
number widely used in email applications, this is the pref- 
erable message identifier for email systems. However, where 
this unique number is unavailable other identifiers may be 
used, including author, date and/or subject matches. Further, 

55 for some messages it may even be advantageous to use other 
relatively unique values, such as CRC or other values, by 
themselves or together with other identifiers. It is relatively 
unimportant for purposes of the invention what the identifier 
is, as long as it is useful within the accuracy demanded by 

60 the system design for retrieving the correct preceding mes- 
sage. 

Once the preceding message has been received by the 
communication server, it uses a counterpart delta routine to 
that of the client to reconstruct a replica of the reply message 
65 from the delta of the optimized reply and the retrieved copy 
of the preceding message. Once reconstructed, the reply 
message is forwarded to the target unit(s), as well as to the 
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outbox or sent mail folder of the client's post oflBce box withindesiredlimits.'I\irDing to FIG. 10, with reference also 
(steps 914-916). While some additional processing and to FIG. 2, one embodiment of such a rate governor is 
network traflSc is required between the communication illustrated. This rate governor operates to track the appro xi- 
server and host, this is relatively inexpensive compared to mate time and/or expense for client use, which can be as 
the savings achieved by using an optimized reply over the 5 simple as timing a circuit-switched connection, or where 
tariffed network between the communication server and packet data is being sent, timing (or estimating based on 
client. size) the time and/or cost of transmitting the packet over the 
While the preceding approach can be implemented with- tariffed network(s). In estimating the transmission value 
out resort to a message index, it can be further optimized by (e.g., cost), a rate governor could better estimate actual costs 
use of indices at the communication server and client. In this by taking into account known pricing factors established by 
case, a full index of each active client's mailbox (or other each network service provider (e.g., rates by time of day, by 
application file(s)) is maintained at both the client and the grade/quality of service (QoS) for packets, by size or band- 
communication server. This index could advantageously be width desired, etc.). These values would be maintained for 
one of the S&S indices 213 and 228 of FIG. 2 designed to application by the rate governor (234 of FIG. 2) as each data 
include all mail (although perhaps with less identifying unit is received to determine an estimated transmission 
information for received mail than for filter-restricted mail, value, 

depending on factors such as the memory available and the In the illustrated case of an email application, upon 

amount of identifying information desirable). When an receiving a client-generated message the QM (or other 

optimized reply is received at the communication server, a appropriate controller entity of the communication server) 

search of the appropriate client index (e.g., first the target passes the pertinent packet information or message param- 

unit, if also an active client, otherwise the client's or 20 eter (e.g., the packet size from the header) to the rate 

originating unit's indices) for the message identifier of the governor, which in this case operates as a packet rate 

preceding message, indicating whether or not the preceding governor (or PRG). The PRG determines from the client 

message has been deleted. When the preceding message's object (or profile store) the amount of use time and/or charge 

identifier is present, the process continues as noted above, in still available (or alternatively, the amount already used, and 

other words by sending the optimized reply to the target unit, 25 limits allowed), and compares the use time remaining (e.g., 

or reconstructing the reply message and forwarding it to the a previously authorized or allocated transmission value) 

target unit. against the value for the message parameter (step 954). 

Replies being sent to the client can similarly use an Preferably several limits are established, including one or 

optimized reply to minimize messaging sizes. Thus, for more alert thresholds. These alert thresholds would serve to 

example, where a reply is received by the communication 30 wara the client each time a certain threshold is passed in 

server which has the client as an addressee, the communi- amounts of time/charge used or remaining, permitting the 

cation server is capable of generating a delta between the client to limit use as needed to stay within budget, or to seek 

reply message and a preceding message known to be stored a higher limit in advance of the point at which the use limit 

inamaildatabase(e.g.,memory214of FIG.2)of Iheclient. is reached. This use or transmission limit serves as the 

The preceding message is most easily identified if an addi- 35 budgeted limit for data transfers. Unless a user is privileged, 

tional identifier is included with the reply for ease of once the use limit is reached further communications/data 

searching in the client's index. However, where such is not transfers are restricted. In the simplest form, such transfers 

included, identifier's can be extracted from the text (e.g., are restricted by alerting the client that the use limit has been 

author, date, recipient, subject) for comparison matching, reached, tenninating the current session and preventing 

Alternatively, a comparison of the text of the reply message 40 further sessions until additional use limit time/charge is 

can be used in determining the preceding message. For authorized. Alternatively, certain messaging could still be 

example, a series of preceding messages could be retrieved permitted (based, e.g., on any filterable criteria — e.g., per- 

for textual comparison; or alternatively an identifying value mitting messages to the administrator but not a further 

for all or selected (e.g., sent) mail can be maintained (e.g., communication unit), but with reminders that routine mes- 

by calculating the text CRC value and storing it in the 45 sages will not be forwarded. This would advantageously 

index), and a check of selected portions (e.g., all portions allow critical messages, messages to an administrator (e.g., 

below insertions identifying preceding messages in the text) requesting additional authorization), etc., to still be 

of the reply message text can then be performed. The latest transferred, although it does not prevent a user from running 

or largest matching preceding message is the selected up excess charges for messaging to the communication 

(which could be either a message sent to, or sent from, the 50 server. A PRG may thus also be advantageously used in the 

client), so as to minimize the delta, and the delta calculated client (e.g., PRG 209 of FIG. 2), signaled by the PRG of the 

between the preceding message and the reply message. An communication server to automatically set certain prestage 

optimized reply is then formed including the delta and filters to restrict all but certain message transfers until a new 

preceding message identifier recognizable by the client. This use limit is provided. If a user were to bypass this client PRG 

optimized reply is then forwarded, and reconstructed at the 55 and continue improper messaging, all fiirther sessions could 

client into the reply message. In other words, the client be terminated by the communication server with notification 

retrieves from memory the message corresponding to the to the administrator and client. 

message identifier, and forms a replica of the reply message if the user is privileged, data transfers would still continue 

from the delta and message. Once acknowledged, both client despite the user limit having been exceeded. However, an 

and communication server indices are appropriately updated alert would still preferably be sent to both the client and 

to reflect the mail transfer (steps 918-930). administrator, allowing the administrator to verify the privi- 

This embodiment thus provides an eflScient process for lege and reset the use limit if desirable, and the client to still 

sending reply data between a client and the communication be aware it has passed a targeted use amount (steps 956-968 

server, without requiring the costly transfer of earlier trans- and 980-984). In any event, after each data transfer the 

mittcd portions of the reply data, 65 client object or store is updated to reflect the new estimated 

In a final embodiment, a rate governor is provided so as transaction total (e.g., time remaining, total expense, etc) 

to assist clients in maintaining their messaging and expenses (step 958). 
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As mentioned above, if a user is not privileged it is 
preferable to allow the client an additional data transfer to an 
administrator requesting additional allocation of time/ 
charges. This request would be forwarded by the commu- 
nication server to the administrator host, where it would be 
processed for approval. If approved, the administrator would 
notify the communication server to adjust the use limit by a 
specified amount. Alternatively, if there is no system 
administrator, but charges or debits are handled through a 
communication server service provider, the client may send 
any appropriate authorization for additional charge/debit to 
the communication server (e.g., by sending an encrypted 
account number and identifying information like a PIN 
(personal identification number). Once the charge or debit is 
processed and approved to the service provider's 
satisfaction, the amount of charge or debit would be used to 
adjust the use limit. A notification would also be forwarded 
to the client of the new use limit, with the client PRG being 
updated accordingly (steps 970-978). 

In addition to updating the use limit in response to a user 
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limited number of which have been described in detail 
above. Thus, for example, while the embodiments above 
describe application to clients communicating in certain 
systems, one should appreciate that it has application to any 
communication system, wired or wireless, client-server, 
distributed or other networks, etc., in which the user is 
remote from a host. It can also be used with almost any 
application program or groups of programs (e.g., transfer- 
ring database, wordprocessing, graphics, voice etc. files, 
executing programs and control messages, etc.), not just 
email or groupware. Moreover, while processor 206, con- 
troller 229, timers 205 and 224, data stores 211 and 225, and 
other circuits, are described in terms of specific logical/ 
functional/circuitry relationships, one skilled in the art will 
appreciate that such may be implemented in a variety of 
ways, preferably by appropriately configured and pro- 
grammed processors, ASICs (application specific integrated 
circuits), and DSPs (digital signal processors), but also by 
hardware components, some combination thereof, or even a 
distributed architecture with individual elements physically 



or administrator request, the rate governor can also be 20 separated but cooperating to achieve the same functionality, 

advantageously set to automatically update the use limits Thus, it should be understood that the invention is not 

upon the occurrence of a predetermined update event. Thus, limited by the foregoing description of preferred 

for example, where billing and budgeting is done on a embodiments, but embraces all such alterations, 

monthly cycle, and the administrator has set rate governor modifications, and variations in accordance with the spirit 

preferences so as to automatically reset the use limit on the 25 and scope of the appended claims, 

first day of the next billing cycle, the communication server claim* 

will automatically re^t the client use limit at the specified ^ ^ ^^^thod of communicating data units over a wireless 

time and m the specified amount (step 992). network between a client communication unit and a host 

Moreover, in order to achieve an even more accurate ^jgyice via a communication server, the method comprising, 

billing control, the communication server could be coupled 30 ^jjg communication server: 
with the tariffed network service provider(s) so as to receive 
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periodic charge statements for client data traffic, as well as 
updates for tariff rates, etc. In order to take advantage of 
these statements, a billing index would be maintained for 
each client estimating use and charges for each data transfer. 
Upon receiving the periodic charge statement (e.g., for- 
warded once a day during an administrative window) the 
estimated use entries are replaced by the actual use and 
charges from the statement, and the client profile (and 
object, if active) is updated to reflect a corrected use limit, 40 
etc. The administrator is notified, and the client is notified 
upon the next transaction, of the updated amount. If desired, 
the client or administrator can request a download of the 
current billing index showing the most recent estimated and 
actual charges (steps 986-990). 

Finally, one should appreciate that the above process is 
equally applicable to groups as well as to individual clients. 
Thus, the PRG can advantageously be used to set use limits 
for groups and supergroups of users, as well as for individual 
clients as described above. Thus, where one of the applica- 
tions being used is groupware, as opposed to the email 
example described above, different groups can be assigned 
group use limits for groupware data transfers (while retain- 
ing individual use limits for separate email or data transfers, 
etc). To avoid one or two users exhausting the group*s 
authorized limit, individual use limits can still be set for each 
chent, although with more flexibility, e.g., to draw on unused 
group time before requiring additional allocation from an 
administrator, to permit another user of the group to yield a 
portion of its individual use limit, etc. As should be apparent, 
many variations exist on how the rate governor is structured, 
depending on the applications being used, clients and groups 
operating, the interactivity with service providers, complex- 
ity or simplicity desired, and many other related and unre- 
lated factors. 

One skilled in the art will appreciate that there are many 
variations that are possible for the present invention, only a 
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filtering data units based on a first set of user-selected 

criteria to produce filtered data units; 
communicating the filtered data units to the client com- 
munication unit; 
receiving a second set of a plurality of user-selected 
criteria, wherein the second set of the plurality of 
user-selected criteria has been previously prepared at 
the client communication unit and, when completed, 
has been sent to the commimication server in a virtual 
session; 

filtering subsequent data units based on the second set of 
the plurality of user-selected criteria to create subse- 
quent filtered data units; and 

communicating the subsequent filtered data units to the 
client communication unit. 

2. The method according to claim 1 further comprising 
truncating a filtered data unit if the fihered data unit exceeds 
a first filter size. 

3. The method according to claim 1 further comprising 
truncating a subsequent filtered data unit if the subsequent 
filtered data unit exceeds a second filter size. 

4. The method according to claim 1 further comprising: 
maintaining a summary index of data units that did not 

pass the first set of user-selected criteria to produce 
unfiltered data units; and 
automatically forwarding the unfiltered data units to the 
client communication unit that pass the second set of 
the plurality of user-selected aiteria. 

5. A method of communicating data units over a wireless 
network between a client communication unit and a host 
device via a communication server, the method comprising, 
at the client communication unit: 

communicating a set of a plurality of user-selected criteria 

to the communication server; 
storing the set of the plurality of user-selected criteria 

locally in a memory; 
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receiving filtered data units from the communication 
server based on the set of the plurality of user-selected 
criteria; 

reviewing the set of the plurality of user-selected criteria 
locally; 5 

modifying the set of the plurality of user-selected criteria 
locally to produce a modified set of a plurality user- 
selected criteria; 

storing the modified set of the plurality of user-selected 
criteria locally in the memory; 

communicating the modified set of the plurality of user- 
selected criteria to the communication server; and 

receiving filtered data units from the communication 
server based on the modified set of the plurality of is 
user-selected criteria. 

6. The method according to claim 5 wherein the steps of 
communicating occurs when a virtual session is established 
between the client communication imit and the communi- 
cation server. 20 

7. The method according to claim 5 wherein the step of 
modifying comprises modifying the set of user-selected 
criteria at the client communication unit while on-line with 
the communication server, 

8. The method according to claim 5 wherein the step of 25 
modifying comprises modifying the set of the plurality of 
user-selected criteria at the client communication unit while 
off-line from the communication server. 

9. The method according to claim 5 further comprising 
providing the client communication unit with several pre- 
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defined groups of filter settings that are selectively commu- 
nicable to the communication server. 

10. The method according to claim 5 further comprising 
providing the client communication unit with several groups 
of filter settings that are manually activated. 

11. A method of communicating data units over a wireless 
network between a client communication unit and a host 
device via a communication server, the method comprising: 

filtering data units, at the communication server, based on 
a first set of a plurality of user-selected criteria to 
produce filtered data units; 

communicating, at the communication server, the filtered 
data units to the client communication unit; 

preparing, at the client communication unit, a second set 
of a plurality of user-selected criteria and, when 
completed, communicating the second set of the plu- 
rahty of user-selected criteria to the communication 
server in a virtual session; 

filtering subsequent data units, at the communication 
server, based on the second set of the plurality of 
user-selected criteria to create subsequent filtered data 
units; and 

communicating, at the communication server, the subse- 
quent filtered data units to the client communication 
unit. 

***** 
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